Identification of users on a network

ABSTRACT

The present invention enables the reading and writing of files stored in the cache of a web browser ( 100 ) without the use of cookies. The user requests an uncokie (hookie) from browser ( 100 ). The browser checks to see if the uncookie is cached within itself ( 102 ). If not, the browser requests ( 110 ) the uncookie from the server.

FIELD OF THE INVENTION

The present invention relates generally to methods and apparatus foridentifying and storing information regarding individual users on anetwork without using cookies.

BACKGROUND OF THE INVENTION

Just as computer networks have gained widespread use in business, theInternet (one example of a computer network) has gained widespread usein virtually every aspect of our lives, owing primarily to thepopularity of the worldwide web. The Internet includes servers(computers), which offer electrical communication to client computers(operated by users) and other servers. The computers involved may rangefrom mainframes to cellular telephones, and they may operate over anyconceivable communication medium.

Most users connect to the Internet (or “surf the net”) through apersonal computer running an operating system with a graphic userinterface (GUI), such as one of the Windows® operating systems. A usercommunicates over the Internet using a program called a “browser”running on his computer, the two most popular ones being InternetExplorer and Netscape, although many other browsers are in common use.The browser receives files in a format known as HTML, which is a mark-uplanguage that permits multimedia to be embedded within formatted andstylized text, and it displays “pages”, which may play sound and exhibitgraphics and video. Various programming languages, such as Javascript,are also available which permit executable code to be embedded in anHTML file and to run and to perform useful tasks when a browser presentsthe file to the user. Those skilled in the art will appreciate thatbrowsers are not limited to use on the Internet, but are now widely usedfor general communication on networks, including Intranets.

Cookies are small files stored inside a web user's computer that areused to save client-specific information. They have been used for theidentification of a computer when negotiating a connection to a server,and they thereby make possible the customization of content oradvertisements transferred to the client computer.

Several tools and commands are built into browsers to manage, read,write and use cookies to store information. Also, administrative toolsare provided to users in order to control access to cookies, evenpreventing their use completely which limits the server's ability toidentify users and therefore tailor content and commercial messagedelivered.

Certain websites, and even the legislatures in a few countries (e.g.Germany), limit the use of cookies because of privacy concerns. Also,some users disable them or constrain their use through custom settingsin the preferences of their browsers. And lately, new versions ofbrowsers add tools to empower users so that they can control access totheir cookies. All this limits the server's ability to identify usersand therefore tailor content and delivery of commercials

In order to circumvent these limitations, the present invention avoidsthe use of the client computer files entirely or delivers cookiefunctionality by making use of a file which is cached in the Internetcache of the user's computer, yet is not recognized by the user'sbrowser as a cookie. This file is stored in the temporary directory usedfor all cached Internet files. It can contain the history of a user andinclude any information that may be utilized to customize content oradvertisement.

In accordance with one aspect associated with a first embodiment, thepresent invention enables the reading and writing of files stored in thecache of a web browser in a completely novel way that until now was onlypossible using cookies. By utilizing this technique, web programmers,content and advertisement servers can overcome the limitations builtinto cookie technology. This aspect of the invention, hereafter referredto as Hookies or Uncookies, allows for the same type of file managementfound in cookies, without resorting to cookie programming. This resultsin increased functionality, since many cookie limitations are avoided,like their file size restrictions and user defined accessibility.

In accordance with another aspect of the invention related to otherembodiments, an identification code is made available in a userscomputer, either as a file stored in the browser cache in the mannerdescribed above or in hardware in the user's computer. Thisidentification code is then matched with records stored in a database.

The various embodiments of the invention can be used, among otherthings, to:

-   -   Identify unique Internet users without using cookies.    -   Identify unique Internet users from a variety of web servers.    -   Maintain updated information about a user without using cookies.    -   Share information about a user across different sites.        -   Override user defined limitations in storing and accessing            information in the user's computer.        -   Preserve information on the user's side despite cookies            being deleted or blocked.

In its preferred form, an Hookie is a JavaScript file with a URL (thetype of identifier used for websites) for a name. Tools exist forprogrammers to manage cookies, which allow for the storage and access ofinformation on the user's side. If a file is not defined as a cookie,there are no special commands provided to manage it. The currentinvention creates this capability Hookies.

The placement of a Hookie, in the computer's Internet cache entails aseries of considerations:

1. It is inherently less durable, since caches are erased periodicallyaccording to preferences.

2. Its access cannot be limited by the user through the modification ofpreferences. Neither can it be blocked by cookie managing software orwebsites that do not allow them.

3. Hookies can contain unlimited amounts of data, unlike cookies.

4. Unlike cookies, which can only be accessed by authorized servers,information stored in Hookies can be accessed by any Uncookie awareserver.

The fourth point leads to an ancillary use of Hookies: sharing userinformation across different servers. This enables the creation of a“site consortium” made up of assorted sites sharing user informationamong themselves, therefore sharing knowledge which could be used toenhance a user's experience.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing brief description, as well as other objects, features andadvantages of the present invention be understood more completely fromthe following detailed description of a presently preferred, butnonetheless illustrative, embodiment in accordance with the presentinvention, with reference being had to the accompanying drawings inwhich:

FIG. 1 is a flowchart illustrating the reading of the data stored in theHookie;

FIG. 2, is a flowchart illustrating the process of updating such data;

FIG. 3 is a flowchart illustrating a second embodiment for cookie-lessuser identification making use of a stored file;

FIG. 4 is a flowchart illustrating a third embodiment for cookie-lessuser identification making use of a stored file;

FIG. 5 is a flowchart illustrating a fourth embodiment for cookie-lessuser identification making use of an identification code stored inhardware; and

FIG. 6 is a functional block diagram illustrating the environment of thepresent invention and some of the fundamental concepts involved.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 6 is a functional block diagram illustrating the environment of thepresent invention and some of the fundamental concepts involved. Aplurality of user or client computers U1 . . . UN are connected to anetwork, such as the internet I. Also connected to the internet is aserver computer S. The server computer and client computers cantherefore communicate through the internet. At least one ID code (see 1. . . Cn) is provided on each client's computer. These code are uniquelyassociated with either the computer or one of the users on the computer.As will be explained further below, the code may be stored either inhardware on the computer or in the form of an electrical signal or filewhich is independent of any cookie. Stored on the network is information(F1 . . . Fn) about each user, and this information is stored inassociation with the respective ID code. As will become clear below, theinformation may either be stored on the client computer or on theserver. In operation, when a client computer communicates with server Sover the internet, the respective ID code is provided to the server. Theserver can then identify the user, can access the user information, andcan update the user information for providing individual content orcommercial messages to the user.

Referring to the flowchart of FIG. 1, reading of the Hookie starts inblock 100 with the execution of a tag in an HTML file that requests theexecution of a program called “Uncookie.dll.” This program produces anHookie file which contains user-related information and is stored in thecache. However, during the read operation of FIG. 1, it is importantthat the cache information is not overwritten. As explained below inblocks 102 and 104, the browser determines whether the Hookie fileresulting from the execution of Uncookie.dll is in the cache and whetherthe Hookie is up to date. These are the normal steps performed by abrowser when a file is requested. If the Hookie is both cached and up todate, the browser reads the Hookie file from the cache (block 106), anduses the data stored in it for parameters for further operations (block108). Such operations could be, for example, getting special content forthe user.

If on the other hand, the Hookie file, is not present in the cache (“no”at block 102) or if the browser determines that it must retrieve anupdated version (“no” at block 104), it automatically performs a requestto the server with which it is communicating (block 1 10). The serverreceives the request and in block 11 2 verifies if it was made fromwithin an iframe (a conventional frame used, for example, for bannerads). If the Hookie is within an iframe (“yes” at block 12), the Hookieis updated. However, in the present instance, the Hookie tag is locatedin the body of the HTML document and not in an iframe, so the result atblock 112 is negative, resulting in an http status code equal to 304(Block 114). This indicates that the file is current and does not needupdating. This avoids delivering a new Hookie file to the browser, whichwould overwrite the old one. The browser then defaults to the Hookiefile in the cache, and if none is stored, uses stored default value(block 106).

The preceding process prevents updating of the Hookie file when readingit. This amounts to providing special treatment for an Hookie, since thebrowser normally updates a cached file automatically when accessing it.As indicated above an Hookie update will be allowed only if requestedfrom within an iframe.

The flowchart of FIG. 2 illustrates the preferred Hookie writingprocess, which begins with the execution of an external updating eventin block 200. As a result of this event, JavaScript code generates aniframe. In block 202, from within the Iframe, execution is requested ofa program called x.dll, using as parameters user data stored in theHookie. The server runs those parameters through the x.dll program inblock 204 and returns the results to the browser. The x.dll programmerely updates the users parameters based upon a pre-programmed sequenceor information stored in a database.

At block 206, JavaScript code generates a form inside the iframe usingthe results of x.dll execution as values. In block 208 the form requeststhe execution of Uncookie.dll. The form is used in order to avoid havingthe browser automatically request the file from the cache, as in blocks102, 104 and 110. Thus special treatment is again obtained for theHookie. The server receives the request and executes Uncookie.dll, asshown in block 210. Since the form was executed inside the iframe, thetest produces a positive result, and the Hookie data is updated in block212. The updated Hookie file is then sent to the browser and stored inthe cache (Block 214).

FIG. 3 is a flowchart illustrating an alternate cookie-less process foruser identification. This embodiment utilizes the Hookie only to storean identification code, doing away with the need to update data on theclient side by hosting all information on the server side. The processbegins at block 300, and an HTML web page or HTML e-mail is receivedfrom a server at block 302. At block 304, the identification processbegins when the HTML code is executed and requests a predefined file,possibly a DLL, file which contains the user identification number.

As with any file, the first place the Internet browser looks for thefile is in the Internet cache, performing a test at block 106 todetermine whether the sought file has been cached. If not, the file isrequested from te server at block 308, and the request is received bythe server at block 310. At block 312, the server then runs a routinewhich generates a unique user identification and places it inside a fileof predetermined name, which. At block 314, the user identification isstored in a database on the server. Then, at block 316, the filecontaining the used identification is sent to the user, where it isplaced in the Internet cache. Then control transfers to block 318.

If it had been determined at block 306 that the file containing the useridentification is in the Internet cache, that file is executed at block318 and requests custom content from the server. That request isreceived by the server at block 320, and it matches the useridentification number with in the request with the user history in thedatabase in block 322, then, at block 324, selects custom content forthe user, based the database information. The user history in thedatabase is then updated at block 326, and the custom data is sent tothe user at block 328. After receiving the custom data, the userexecutes it at block 330, and the process ends at block 332.

FIG. 4 is a flowchart illustrating another alternate embodiment of acookie-less process for user identification which stores only anidentification code in the Hookie. It will be appreciated that themethod of claim to is identical to the method of FIG. 3 through block324. Following block 324, the custom content is sent to the user atblock 328, following which it is executed at block 330. Thereafter, theuser makes a new request at block 334, which is received by the serverat block 336. The server then updates the user history at block 326, andthe process ends at block 332.

The method can be used to identify specific web surfers, so thatcustomized content can be delivered to them when accessing a site ordelivering an advertisement. It can also be used with HTML e-mails. Asexplained above the method can also be used to identify users acrossdifferent servers

The fourth embodiment of the invention (FIG. 5) provides cookie-lessidentification of a user by making use of an identification codeembedded in hardware.

The method currently described can be implemented across the Internet oron all types of networks. It can be used when serving HTML content, webor mail, or it can be built into all kinds of software. This methodrelies on a feature built into all networking devices called MacAdress.MacAdress refers to a unique identifier given to all active networkingdevices (modems, nic cards, etc. . . . ) present on a any network. Thisidentifier is built into the hardware, cannot be modified, is unique andever-present. It is utilized during the transaction of informationpackets between connected network appliances.

The MacAdress of all active devices inside a computer can always beaccessed from such computer. Within a network, the MacAdress can beaccessed if and only when no metric changes or masking takes place andthe Netbios ports are left opened. The MacAdress can be accessed from aremote server across the web only in those cases when there is no metricchange. If the user is accessing the web through a proxy or a gateway,the remote server cannot see the device's ID.

This limitation presents the following bifurcation in the preferredprocedures:

-   -   1. A method for when the MacAdress can be accessed remotely.    -   2. A method for when the MacAdress cannot be accessed remotely.        In the first case, described as a situation in which a “layer 1”        or physical connection is possible, the identification of the        user would be achieved directly and the flow of information        would follow the path A described in flowchart of FIG. 5. In the        second scenario, a program running locally at client computer        would read the MacAdress and pass the data on to the remote        server. This flow is charted in path B of the flowchart.

Turning now to FIG. 5, the process starts at block 500. At block 510,the user requests authentication, and the server requests a TCP/IP layer3 and 4 connection at block 512. Layers 3 and 4 are the network andtransport layers, respectively. At block 514, the service supportstructure is analyzed and, at block 516 determination is made whether ornot the layer 1 connection is possible. If it is, operation proceeds toblock 518 (path A) where a layer 1 connection is established. At block522, the MacAddress from the user's computer is received, and control istransferred to block 526.

If it was determined at block 516 that a layer 1 connection is notpossible, the server sends a program to the client which seeks aMacAddress locally at the client (block 520—path B). The server wouldtypically do this in response to a file request by the client. TheMacAddress at the client is retrieved (block 524) and sent to theinformation server (block 524). At which point, control is transferredto block 526.

At block 526, the MacAdress is matched with the information and thedatabase, and it is then authenticated (block 528), at which point theuser's identity has been established. At block 530, customized contentis generated and sent to the user, and the process terminates at block532.

More About Uses:

1. Customize content

2. Customize advertisements

3. Limiting site access to specific computers

By limiting access to information to registered devices, eventual snoopsor hackers could not break into servers without physically entering thesite containing authorized computers.

4. Enhancing transaction security

Tying all transactions to a specific machine, fraudulent transactionscould be traced back to the originating hardware.

5. Copy-protecting software or limiting its installation to specifichardware

This would limit the functionality of a given piece of software torunning it only on an authorized machine. Also, all documents created bysuch software could include an id linking them to the original machinein which they were created.

6. locate hardware Geographically

This can be achieved because of the way in which MacAdresses areassigned: regionally.

1. For use in a network including a server computer and a plurality ofclient computers connected for communication with the server through thenetwork, a method for identifying one of the client computers or a userof the one computer, comprising the steps of: maintaining on the oneclient computer an identification signal representing an identificationcode which is unique to the one client computer or one user of thatcomputer, the identification signal being independent of any cookie;storing on the network and in association with the identification signalclient information signals representing information related to theclient computer or the one user; and providing the identification signalfrom the client computer to the server computer when the client computercommunicates with the server computer over the network.
 2. The method ofclaim 1, utilized in a system wherein the network is the Internet andthe one client computer has an Internet cache, the identification signalbeing stored in an identification file in the Internet cache of the oneclient computer, identification file not being defined as a cookie inthe one client computer.
 3. The method of claim 2, wherein at least aportion of the information signals is stored in the identification file.4. The method of claim 3, wherein the information in the identificationfile is matched to information stored on the server computer.
 5. Themethod of claim 1, wherein at least a portion of the information signalsis stored in the server computer.
 6. The method of claim 1, wherein theidentification signal being available in a hardware component in the oneclient computer.
 7. The method of claim 6, wherein the identificationsignal being the Mac Address of a network card in the one clientcomputer.
 8. The method of claim 1, wherein a copy of the Mac Address ofa computer which communicates with the server computer is stored on theserver computer and is subsequently compared to the Mac Address receivedfrom a client computer to verify the identity thereof.
 9. In a networkincluding a server computer and a plurality of client computersconnected for communication with the server through the network, animprovement for identifying one of the client computers or a user of theone computer, comprising: an identification signal representing anidentification code which is unique to the one client computer or oneuser of that computer stored on the one client computer, theidentification signal being independent of any cookie; clientinformation signals representing information related to the clientcomputer or the one user are stored on the network and in associationwith the identification signal; and executable in the one clientcomputer providing the identification signal from the client computer tothe server computer when the client computer communicates with theserver computer over the network.
 10. The improvement of claim 9,utilized in a system wherein the network is the Internet and the oneclient computer has an Internet cache, the identification signal beingstored in an identification file in the Internet cache of the one clientcomputer, identification file not being defined as a cookie in the oneclient computer.
 11. The improvement of claim 10, wherein at least aportion of the information signals is stored in the identification file.12. The improvement of claim 11, further comprising a comparatormatching the information in the identification file to informationstored on the server computer.
 13. The improvement of claim 9, whereinat least a portion of the information signals is stored in the servercomputer.
 14. The improvement of claim 9, wherein the identificationsignal is stored in a hardware component in the one client computer. 15.The improvement of claim 14, wherein the identification signal being theMac Address of a network card in the one client computer.
 16. Theimprovement of claim 9, wherein a copy of the Mac Address of a computerwhich communicates with the server computer is stored on the servercomputer, and further comprising a comparator which compared to thestored Mac Address to the Mac Address received from a client computer toverify the identity thereof.
 17. The method of claim 2, wherein a copyof the Mac Address of a computer which communicates with the servercomputer is stored on the server computer and is subsequently comparedto the Mac Address received from a client computer to verify theidentity thereof.
 18. The method of claim 3, wherein a copy of the MacAddress of a computer which communicates with the server computer isstored on the server computer and is subsequently compared to the MacAddress received from a client computer to verify the identity thereof.19. The method of claim 4, wherein a copy of the Mac Address of acomputer which communicates with the server computer is stored on theserver computer and is subsequently compared to the Mac Address receivedfrom a client computer to verify the identity thereof.
 20. The method ofclaim 5, wherein a copy of the Mac Address of a computer whichcommunicates with the server computer is stored on the server computerand is subsequently compared to the Mac Address received from a clientcomputer to verify the identity thereof.
 21. The method of claim 6,wherein a copy of the Mac Address of a computer which communicates withthe server computer is stored on the server computer and is subsequentlycompared to the Mac Address received from a client computer to verifythe identity thereof.
 22. The method of claim 7, wherein a copy of theMac Address of a computer which communicates with the server computer isstored on the server computer and is subsequently compared to the MacAddress received from a client computer to verify the identity thereof.23. The improvement claim 10, wherein a copy of the Mac Address of acomputer which communicates with the server computer is stored on theserver computer, and further comprising a comparator which compared tothe stored Mac Address to the Mac Address received from a clientcomputer to verify the identity thereof.
 24. The improvement claim 11,wherein a copy of the Mac Address of a computer which communicates withthe server computer is stored on the server computer, and furthercomprising a comparator which compared to the stored Mac Address to theMac Address received from a client computer to verify the identitythereof.
 25. The improvement claim 12, wherein a copy of the Mac Addressof a computer which communicates with the server computer is stored onthe server computer, and further comprising a comparator which comparedto the stored Mac Address to the Mac Address received from a clientcomputer to verify the identity thereof.
 26. The improvement claim 13,wherein a copy of the Mac Address of a computer which communicates withthe server computer is stored on the server computer, and furthercomprising a comparator which compared to the stored Mac Address to theMac Address received from a client computer to verify the identitythereof.
 27. The improvement claim 14, wherein a copy of the Mac Addressof a computer which communicates with the server computer is stored onthe server computer, and further comprising a comparator which comparedto the stored Mac Address to the Mac Address received from a clientcomputer to verify the identity thereof.
 28. The improvement claim 15,wherein a copy of the Mac Address of a computer which communicates withthe server computer is stored on the server computer, and furthercomprising a comparator which compared to the stored Mac Address to theMac Address received from a client computer to verify the identitythereof.